微服務架構模式是一種開發單一應用程式的方式，將其視為一系列小型服務，每個服務都在自己的程序中執行，並透過輕量級機制（通常是 HTTP 資源 API）進行通訊。這些服務圍繞著商業功能建構，並可透過全自動部署機制獨立部署。這些服務的集中管理非常少，它們可能使用不同的程式語言撰寫，並使用不同的資料儲存技術。雖然它們的優點讓它們在過去幾年非常流行，但它們也伴隨著增加的分配、減弱的一致性，並需要在營運管理方面具備成熟度。

大多數內部 REST API 都是一次性的 API，專門建置於單一整合點。在本文中，我將討論非公開 API 的約束和彈性，以及跨多個團隊進行大規模 RESTful 整合的經驗教訓。

一個模型（由李奧納多·理查森開發），將 REST 方法的主要元素分解為三個步驟。這些步驟引入了資源、http 動詞和超媒體控制。

我的同事吉姆·韋伯以在企業中採用輕量級和以業務為導向的整合方法而聞名。他還以是一位非常強大且有趣的演講者而聞名。因此，我既緊張又興奮地與他在 QCon 2008 年的主題演講中同台。他做了一個非常有趣的簡報，其中穿插了一些嚴肅的要點。然後，我們就開始了 - 也許是受到演講前的品脫啤酒的幫助。我們談到了企業整合的歷史、自以為強大但實際上只是肥胖的系統的增長、敏捷思維的作用、網路的影響（包括吉姆關於網路發明的獨特理論），以及這如何導致游擊隊 SOA。

本文討論了服務供應商和消費者社群演進時面臨的一些挑戰。它描述了當服務供應商變更其合約的某些部分，特別是文件架構時，所產生的某些耦合問題，並找出兩種廣為人知的策略 - 加入架構擴充點和對接收到的訊息執行「剛好足夠」的驗證 - 來緩解這些問題。這兩種策略都有助於保護消費者免於供應商合約的變更，但它們都沒有讓供應商了解其使用方式以及其在演進時必須維持的義務。本文根據其中一種緩解策略 - 「剛好足夠」驗證策略 - 的基於斷言的語言，描述了「消費者驅動合約」模式，該模式讓供應商了解其消費者義務，並將服務演進集中在提供消費者所要求的主要業務功能上。